Zwiększanie poziomu bezpieczeństwa stron www
Dawno nie było wpisu poświęconego bezpieczeństwu stron www, a że kilka dni temu dostałem najnowszy numer â 11/2008 - czasopisma HACKIN9 to mi trochę ułatwiło sprawę. Ułatwiło, bo w tym numerze jest artykuł poświęcony bezpiecznym stronom. Dzisiaj skupię się na kilku fajnych sztuczkach z katalogami, plikami przechowującymi dane wrażliwe (loginy i hasła) do poprawnego działania naszej aplikacji i bezpieczeństwie bazy danych.
Poprawnie zaprojektowana aplikacja wszystkie dane będzie przechowywać w jednym miejscu, jak to zostało ujęte w hacking9 - centralizacja danych wrażliwych. Trzymanie wszystkich danych w różnych plikach, to generalnie zły pomysł. Jeżeli intruz w jakiś sposób zdobędzie dostęp do naszego serwisu lub struktury plików, to wszystko ma ładnie podane na tacy â to raz. Kolejna sprawa to modyfikacja takich danych. Jeżeli chcemy zmienić hasło do bazy danych, to trzeba zmieniać je w X miejscach.
Mając takie dane np. do bazy danych, to już tylko wyobraźnia go ogranicza z tym co chce zrobić z tymi danymi. Zrobić można dużo, pobrać maile użytkowników i na przykład sprzedać spamerowi. Można jeszcze umieścić jakieś kompromitujące informacje a nawet szantażować. Także z takimi danymi można poszaleć, a im większy serwis lub firma to robi się ciekawiej.
Artykuł, który przykuł moją uwagę to „Bezpieczeństwo aplikacji internetowych”. Opisane są tam metody skutecznej ochrony tych wrażliwych danych. Autor w tym artykule pisze, że dostęp do danych w katalogu public_html/
jest różny. Wszystko zależy od ustawień serwera. W zależności od serwera, znajdować się tam mogą specjalne katalogi, do których można się dobrać poprzez wpisanie go w adresie strony np. www.domena.pl/stats
. Ten konkretny katalog stats/
, to systemowy katalog ze statystykami zbieranymi przez serwer. Teraz, jeżeli ktoś zna np. framework w którym jest napisana aplikacja, to w podobny sposób (znając strukturę plików) można uzyskać dostęp do plików konfiguracyjnych. W frameworku Agavi plik xml z danymi do bazy danych jest pod tą ścieżką: app/config/databases.xml
â teraz jeżeli nie ma ustawionych odpowiednich uprawnień do plików xml (np. w .htaccess) to... patrz akapit wyżej.
Do czego zmierzam. Ważne jest aby w naszej aplikacji maksymalnie utrudnić dostęp do tych wrażliwych danych. W artykule jest podpowiedź, aby wszystkie pliki aplikacji (klasy, configi) przechowywać w katalogu wyżej, a w pliku index.php (który jest w public_html/
) umieścić tylko jedną funkcję â include().
Ta sztuczka pomimo swojej prosty â paradoksalnie â jest rzadko stosowana. Z tym stwierdzeniem autora zgadzam się w zupełności, bo widziałem już różne skrypty pisane przez różne osoby. Ciężko się przyznać, ale do pewnego momentu, też tego nie robiłem. Pamiętacie aferę z bankiem? Tutaj takie rozwiązanie na pewno by pomogło!
Co w przypadku uzyskania dostępu do tych danych (np. baza danych)? Odpowiedź jest prosta â minimalne przywileje dla użytkowników w obrębie bazy danych oraz jak sprytnie zauważył autor tego artykułu â rozrzucić dane po kilku bazach danych. Ograniczenia poleją na tym, aby uniemożliwić intruzowi usunięcie danych czy nawet skasowanie tabel. A rozrzucenie danych to bardzo ciekawy pomysł, bo zwykła strona (produktowa, dla klientów) potrzebuje tylko tak naprawdę odczytywać informacje z bazy. Zaś dla panelu administracyjnego jest tworzony inny użytkownik z nowymi prawami dostępu.
Artykuł mi trochę rozjaśnił w sprawach bezpieczeństwa stron, pokazał kilka nowych fajnych pomysłów. Ponadto znajdują się tam przykładowe metody sprawdzania danych wejściowych takich jak: ciągi znaków czy sprawdzanie licz (czy na pewno są liczbami).
Komentarze 4
Też czytałem ten numer, coś za bardzo streściłeś ten artykuł :D
A ja się zastanawiam, czemu akurat za przykład podałeś Agavi :> Akurat uważam go za jeden z bezpieczniejszych frameworków... w dodatku, o losie, jest on niszowy, więc wątpię, że potencjalny hakier będzie wiedział co i jak znaleźć.
Pozdrawiam
P.S Struktura Agavi jak (i chyba Symfony) naturalnie skłania ku składowaniu plików projektu ponad public_html.
Hehe, agavi dałem jako przykład, bo za sprawą jednego ewangelisty zapoznałem się z frameworkami, a dwa miałem go pod ręką. Co do struktury tych frameworków to jest dokładnie tak jak piszesz - w taki właśnie sposób są "stworzone"
ciekawy artykuł, ale tak jak autor zaczął, większość rzeczy jest powszechnie znana, gorzej ze stosowaniem
Odnośnie tego numeru HACKIN9 i bezpieczeństwa do dużo ciekawszy jest artykuł "Hakowanie RSS feeds", a na to jeszcze mniej ludzi zwraca uwagę.